Due to increasing reliance on network-accessible devices, network security has become a major issue for organizations and individuals. To help ensure the security of their devices, organizations and individuals frequently install security devices between their private networks and public networks. A security device attempts to prevent unwanted or malicious information generated by the public network from affecting devices in the private network. The security device may also provide network address translation (NAT) functionality, which enables the private network to utilize a single public Internet protocol (IP) address when communicating with the public network. NAT may provide further security from the public network by obscuring the internal structure of the private network from the public network, as well as, reduce costs associated with maintaining a public IP address for each device located within the private network.
One example of a commonly deployed security device is a firewall. A firewall may perform NAT by re-writing the source and/or destination IP addresses included within packets that flow through the firewall. Upon receiving a packet from a private network device designated for the public network, the firewall, for example, re-writes the private IP source address assigned to the private network device with the single public IP address. Upon receiving a return packet in response to the private network device's packet, the firewall re-writes the destination address of the return packet with the appropriate private IP address. In this manner, the firewall obscures the internal structure of the private network by making it appear that only one device, e.g., the firewall, sends and receives data via the single public IP address.
While a firewall that performs NAT may obscure the structure of the private network and thereby provides added security, the firewall may also prevent the private network devices from participating in certain network protocols. For example, a private network device behind a NAT firewall may not act as a transmission control protocol (TCP) server. That is, the private network device may not be able to directly receive and accept a TCP session request from a management device on the public side of the NAT firewall because the IP address of the private network device itself is not known by management devices on the public side of the firewall. The management device only knows the single public IP address used by the firewall. Because TCP requires a management device to know of the IP address of the particular network device with which the TCP session is to be established, the management device cannot directly establish a TCP session with the network device behind the NAT firewall. Moreover, many of the secure protocols that operate over a TCP session may not be utilized, as these secure protocols depend on the TCP session.
Some techniques may be employed that enable a management device on one side of the security device, which may implement port mapping, to establish a secure session (e.g., a secure shell (SSH) protocol session) with a network device on the other side of the security device such that the secure session roles are correctly assigned between the management device and the network device. With such techniques, the management device and the network device may dynamically switch roles as a networking stack is instantiated on the devices for supporting the secure protocol session. For example, the techniques allow the network device to proactively initiate a TCP session with the management device as a TCP client and, upon establishing the TCP session, dynamically switch roles so as to allow the management device to act as a client for any secure communication protocol running on top of the TCP.
In this way, the management device can be properly configured to act as a SSH client and the network device can be configured to act as a SSH server. By properly initiating the SSH secure session from the management device, the secure SSH session can be established in a manner that is correct in terms of the roles each of the network device and the management device perform. Thus, network administrators may more consistently configure the network device and the management device, thereby better assuring both performance and security within the network.
For example, a network device on a private side of a NAT firewall initiates a TCP connection to establish a TCP session with a management device on a public side of the NAT firewall such that the management device accepts the TCP session as a TCP server and the network device acts as a TCP client. In this way, the limitations or restrictions introduced by the NAT firewall can be avoided. After establishing the underlying TCP session in this manner, the network device sends a role reversal message to the management device via the TCP session. The role reversal message specifies an identity of the network device and provides the management device with the ability to securely initiate the secure session, and thereby reverse the client/server roles with respect to the secure session from that of the underlying TCP session.
Upon receiving the role reversal message, the management device initiates a secure connection over the TCP session in accordance with a secure protocol such that the management device acts as the secure protocol client and the network device acts as the secure protocol server. The secure protocol, such as the SSH protocol, enables the secure protocol server (i.e., the network device) to provide a public key (e.g., a SSH host key) to the secure protocol client (i.e., the management device). The SSH host key may provide authentication credentials for the secure protocol server (i.e., the network device) so that the secure protocol server may be authenticated by the secure protocol client. The secure protocol client (i.e., the management device) may receive the SSH host key, and may verify or authenticate the SSH host key by comparing the SSH host key to a database of previously-received SSH host keys. If the SSH host key is verified, the network device and the management device may establish a secure connection between each other over the TCP session.
However, if this is the first time a secure connection is initiated between the network device and the management device, the management device may not be able to verify the SSH host key since the SSH host key will not be present in the database of previously-received SSH host keys. Such a scenario may exist when a new network device is installed in a private network. In such a situation, an end user (e.g., a network administrator) of the network device may be required to manually authenticate the network device, which may take an inordinate amount of time (e.g., a few days). The manual process may involve the end user manually generating a certificate signing request (CSR) for the SSH host key, and manually providing the CSR to a certificate authority (CA) having a chain of trust to a trusted CA. The end user may request that the CA sign the CSR so that a signed, trusted certificate with the SSH host key embedded therein may be created. The end user may then manually load the signed, trusted certificate to the network device. The signed, trusted certificate may enable the management device to verify the SSH host key, and a secure connection may be established between the network device and the management device.
In another manual process, the end user may manually retrieve a fingerprint of the SSH host key. However, this manual process is onerous since it must be performed on a per-device and per-user basis.